Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000009_owner-urn-ietf _Sun Nov 3 17:18:15 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA22518 for urn-ietf-out; Sun, 3 Nov 1996 17:18:15 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA22512 for <[e-mail]>; Sun, 3 Nov 1996 17:18:12 -0500
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA18485  (mail destined for [e-mail]); Sun, 3 Nov 96 17:18:10 -0500
Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA12973; Sun, 3 Nov 1996 17:18:09 -0500
Message-Id: <[e-mail]>
From: [e-mail] (Leslie Daigle)
Date: Sun, 3 Nov 1996 17:18:08 -0500
In-Reply-To: Daniel LaLiberte's message as of Nov  3,  1:48
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Daniel LaLiberte <[e-mail]>,
        "Karen R. Sollins" <[e-mail]>
Subject: Re: [URN] some comments
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (Leslie Daigle)
Errors-To: [e-mail]

Dan,

For all the words that have flown about on this mailing list in the past
few days, I don't really think you've made it clear what you want out
of this particular thread.    Let me be fairly blunt in my interpretation
here, and you can tell me on which counts I have misunderstood you.

I think there are 2 separate things in what you have been saying:

    . whether or not URNs are any different than URLs
    . whether or not URNs can be implemented using URL mechanisms

These are 2 very separate issues.  Let me say, as co-chair of this working
group, that this WG starts from the premise that there _is_ a difference
between URNs and URLs, and that our chartered purpose is to refine an
architecture and experimental implementation that does not centre on
starting from URL mechanisms.

That purpose was selected after a process of consideration and consensus
gathering (i.e., not unanimity, but a bulk of people suggesting they thought
it had merit).  To stick to our charter need not demonstrate the dogmatism
or close-mindedness that I felt you were suggesting in your last mail
to Karen -- it is a reflection of the fact that this is a directed effort.

>From that standpoint, it is quite useful to consider other viewpoints and
implementation mechanism insofar as the contribute a positive step towards
defining, refining, explaining, or implementing the goal -- a sanity check,
even.  But, if you want to sit back and discuss the relative merits of different
ways of how URIs could (have) be(en) implemented, you need to find a different
discussional forum.  I.e., I'm not saying it isn't valid/interesting
discussional material -- I'm saying it's not for this space.

> tomorrow.  But I want to challenge the notion that we shouldn't rethink the
> work of the last several years.  For one thing, for the last 2 years, I
> (and a few others) have been arguing against the split in names vs locations,
> so why should that work be ignored?

Dan, I think your frustration is misplaced.   It is not that it "_is_"
being ignored -- it is not being discussed _here_, because the starting premise
for this WG is that it is not applicable.  If you accept the basic
premise of this working group, _and_ you still feel this is important, then
the problem is that you have not adequately communicated to the people on
this list _how_ your position is _not_ just completely at odds with everything
we're trying to do (and, by the way, I would point out that it was in one
of _your_ postings that you referred to "what you guys are doing" or some
such terminology).

> This is not a matter of just agreeing on a definition - it is a matter
> of having definitions that make sense.

A relative term -- I think the definitions make perfect sense.

> But it is something that the client gets to decide!  And the reason is
> that "identifier of resource" vs "identifier of location of resource"
> doesn't make sense.  It is the chosen resolution mechanism that
> determines how you get from an identifier to the resource.  The
> identifier does *not* determine the resolution mechanism, although
> there may be conventions and globally agreed on mechanisms available.
> The client *can* make the choice of how to resolve an identifier.  It
> is a fact of life in a free society that clients can do whatever they
> want.  (They can't always get away with it, though.)

Without talking about resolution mechanisms, let me say this:  a client
_cannot_ decide, for any given string, "I want the thing this identifies",
or "I want the thing at this location".  Quite simply, if the client has the
identifier of a location, it does not know _what_ the (intended) content
is.  This is _not_ a client decision.

Consider this completely abstract example:

    . Location identifier:  "the third thing from the right on the
      fourth shelf down"

    . Content identifier: "Moby Dick"

If I am a client, holding the string "the third thing...", the only content
I can refer to is whatever is there now -- I have no clue about what
was there when location identifier was written down (included in an
electronic document, beamed to my Newton, _whatever_).  If the shelf has
been re-arranged since this location was made, I will get whatever is there
now.  On the other hand, if I have "Moby Dick", I don't _care_ where it is
now, where it was before, where it will be in the future or what I might have
to do to get hold of it.

The premise of this WG is that there is the need to be able to identify _what_
(i.e., content) one is looking for, as a separate task from identifying
the location from which one wants content.

If I have understood your position correctly, you are saying that there
is no need for a new mechanism for retrieving things from shelves by name --
we'll just build new URL schemes wherein  it is promised that shelves
are never re-ordered (or at least, if they are, transparent pointers are
used to continue the process to find the content that used to be located
on a particular position), and thus the location description can be used
as a unique, naming identifier.

Here's my view on what has happened:  to follow the above analogy a bit
further, URLs are used to retrieve content by instructing something
(call it a librarian in this case; in electronic terms, it is a scheme
resolution process) to retrieve the content from a particular shelf and
position.   The URN proposal says "get me Moby Dick", and identifies
a process whereby the librarian can figure out which  shelf and object
to retrieve.  Because these (currently) look like much the same process,
except for the implied longevity of the identifier, you are saying they
are the same.  I disagree.  I think the URN approach is based on fundamentally
different principles -- that it shall continue to be relevant long after
shelves and objects are no longer useful mechanisms, and therefore they
should _not_ play _any_ role in the naming process.  I don't care if
current URL and URN resolution mechanisms are isomorphic -- I am interested
in defining the baseline implementation for the first generation of
content identification strings -- divorced from location identification.

I furthermore believe that the client (user or program) must be able to
determine by some non-network-based mechanism, whether or not the
identifier in hand is that of a location or of content.

So, to sum up, the basic premises of this working group:

    . there is a difference between content identification and
      location identification

    . we have one proposed architecture for supporting the creation
      of effective content identifiers, and the use of these to determine
      content/location at any given point in time (resolution), and
      this is what we are working to refine.

Dan, please tell me where I have missed your point...

Leslie.

--

----------------------------------------------------------------------------

  "The light at the end of the tunnel             Leslie Daigle
     is often the blindingly obvious..."          Vice President, Research
                                                  Bunyip Information Systems
                      -- ThinkingCat              [phone]
                                                  [e-mail]
----------------------------------------------------------------------------